home *** CD-ROM | disk | FTP | other *** search
/ TeX 1995 July / TeX CD-ROM July 1995 (Disc 1)(Walnut Creek)(1995).ISO / tex-k / tex-k-archive.past / tex-k-archive.gz / tex-k-archive / 000401_kb@cs.umb.edu_Wed Mar 16 00:43:28 1994.msg < prev    next >
Internet Message Format  |  1994-10-11  |  3KB
  1. Received: from terminus.cs.umb.edu by cs.umb.edu with SMTP id AA24841
  2.   (5.65c/IDA-1.4.4 for <tex-k-exp@cs.umb.edu>); Wed, 16 Mar 1994 05:43:29 -0500
  3. Received: by terminus.cs.umb.edu id AA26915
  4.   (5.65c/IDA-1.4.4 for tex-k); Wed, 16 Mar 1994 05:43:28 -0500
  5. Date: Wed, 16 Mar 1994 05:43:28 -0500
  6. From: "K. Berry" <kb@cs.umb.edu>
  7. Message-Id: <199403161043.AA26915@terminus.cs.umb.edu>
  8. To: fj@iesd.auc.dk, tex-k@cs.umb.edu
  9. Subject: Re: Kpathsearch -- database searching
  10.  
  11. I had intended the match function in db.c to deal with two identically-named
  12. files in the db -- ricoh/cmr10.300pk and cx/cmr10.300pk, for example.
  13. If the path looks /sys//ricoh, the db should return the first; if the
  14. path is /sys//cx, the latter.
  15.  
  16. Right now, you'll get whichever comes first in the hash table (last in
  17. the ls-R file, I think).
  18.  
  19. Looking for ./cmr10.300pk first (if the path is .:/sys... and an ls-R
  20. existed in /sys) was something I hadn't thought of. Of course we
  21. shouldn't be looking in the db at all for a path element of `.'. So now
  22. I just check if the directory of the db file is a prefix of the path
  23. element before trying the db.  That fixes that problem.
  24.  
  25.     The question is how to make
  26.     this differentiation: Is it simply built into the code that files
  27.     found in a certain path (e.g., TEXINPUTS) are supposed to exist?  Or
  28.     do we provide some way to configure Kpathsearch, i.e., a way to tell
  29.     it that certain paths (or even certain parts of the paths) are
  30.     supposed to be searched by db only.
  31.  
  32.     I prefer the latter approach.
  33.  
  34. Well, I suppose in theory I would prefer some runtime configuration,
  35. too, but I don't see any easy way to do this.
  36.  
  37. It's not a function solely of the path being searched on; the program
  38. being run is also a factor. For example, when xdvi looks for a VF file
  39. it need not exist, but when vftovp looks for a VF file, it must exist.
  40. When TeX does a \input, the file must exist. But when TeX does an
  41. \openin, it need not. The same search paths are involved in each case.
  42.  
  43. Thus, each file search in the sources has to be examined.
  44. Sigh.
  45.  
  46. The reason I'm willing to go to all this trouble is I think that it's
  47. very important that if a file (foo.tex, say) *does* exist, but is *not*
  48. in the database, that TeX should find it. There is nothing more
  49. frustrating than installing something and then having to regenerate a
  50. zillion subsidiary databases for it to actually be available.
  51.  
  52. Perhaps I am being overzealous about this, since the database could be
  53. regenerated every hour (probably even more often) without any meaningful
  54. performance hit, but it just seems intuitively wrong to me to rely on
  55. that one file to find everything.
  56.  
  57. (For one thing, it would mean all the effort I put in implementing
  58. efficient searches on the filesystem would be useless :-)